The present invention relates to protocol testing, and more particularly to a method of setting up a communication procedure between instances, with one of the instances being a protocol tester, and to a protocol tester using the method.
In the field of protocol testing it is necessary to clearly specify a communication procedure by which a test is described so that the procedure may be executed automatically by a protocol tester. Languages such as TTCN (Tree and Tabular Combined Notation) make this possible, but they are complex and difficult to understand for an untrained reader. TTCN has prevailed in the field of Conformance Testing because these tests are very comprehensive, and TTCN supports such comprehensive tests very well. Apart from that, there are various proprietary test description languages. To facilitate understanding a standardized language, MSC (Message Sequence Charts), is used for the purpose of documenting and describing simple procedures. Further details on MSC may be taken from ITU-T Z.120, the contents of which are incorporated herein by reference. MSC consists of standardized process flow diagrams, also referred to as arrow diagrams or X diagrams. These diagrams may be understood independent of programming language. However, automatic execution of communications described by MSC is not possible on protocol testers. To obtain tests that are executable it is, therefore, necessary to write so-called “scripts”, which requires that the user becomes thoroughly acquainted with the relevant programming language. In addition it is necessary to prepare documentation that is generally understood. For a test it is, therefore, necessary on the one hand to prepare graphical and textual documentation and on the other hand a source code or binary code that may be executed.
This state of the art results in a number of disadvantages. It is frequently necessary to convert existing tests, so there is a risk of inconsistencies. The test communication specifications often do not contain information on the configuration, or at least not in a format that may be read by a machine or by man. The different languages often represent proprietary approaches, which differ from equipment to equipment and have to be learned anew. The user is not supported or only receives rudimentary support with protocol knowledge when creating the messages and events.
What is desired is a method, and protocol tester using the method, that overcomes the above-noted disadvantages.